Controlled streaming of segmented content

ABSTRACT

Methods and systems for enabling client-controlled streaming of segmented content are described. In one example, the client-controlled streaming is on the basis of a manifest file, the manifest file including one or more segments identifiers and one or more associated segment locators. In one example, a method involves: requesting the delivery of at least one segment on the basis of a first segment identifier selected from the manifest file; on the basis of the first requested segment, selecting a second at least one segment identifier from the manifest file, the second segment identifier being associated with an expected future segment request; and pre-resolving a first segment locator associated with the selected second segment identifier for obtaining network information associated with the first segment locator.

FIELD OF THE INVENTION

The invention relates to controlled streaming of segmented content and,in particular, though not exclusively, to a method for enablingcontrolled streaming of segmented content, a client for controllingstreaming of segmented content, a network node and a data structure foruse with a client and a computer program product using such method.

BACKGROUND OF THE INVENTION

Currently an increasing number of video streaming techniques make use ofso-called segmentation. For example, HTTP adaptive streaming (HAS),Scalable Video Coding (SVC) and spatially segmented video (e.g. tiledvideo) use segmentation on the basis of time, quality and spacerespectively. During the segmentation process a so-called manifest filewill be generated which describes the relation between the differentsegment files and/or streams and the location where the segments may beretrieved. A segment file may relate to a file comprising segment data,which may be retrieved by a file retrieval protocol, e.g. HTTP or FTP.Similarly, a segment stream may relate to a stream comprising segmentdata which may be retrieved by a streaming protocol, e.g. RTSP/RTP orHAS. A segment file or stream hereafter will be referred to as asegment. Further, video, or more in general, content rendered by asegmentation scheme may be referred to as segmented content.

Segmented content may be used to dynamically adjust to changingbandwidth requirements, e.g. by switching from a high to a low qualityvideo stream. Moreover, segmented content may also allow fordiscrimination between popular and less popular video segments. Forexample, typically content associated with the beginning of a video willbe watched (downloaded/accessed/retrieved) more often (more popular)than content at the end. Similarly, low-bitrate lower-quality videocontent (e.g. the lowest resolution HAS segments or the SVC base layer)will be watched (downloaded/accessed/retrieved) more frequently thanhigh quality content (e.g. higher-resolution HAS segments or an SVCenhancement layer).

Hence, when segmenting content, certain segments will be (much) moreoften requested by consumers than other segments. This property may beadvantageously used by a content delivery network (CDN), which isconfigured to deliver content to a consumer. It may for example storethe segments associated with more popular content at multiple nodes inthe CDN so that the bandwidth problem (as getting many popular segmentsfrom a too remote server may clog up network bandwidth) may be reducedand efficient delivery is guaranteed. A CDN content location manager maycentrally manage the locations within the CDN where the segments may beretrieved.

In order to enable a client to access segments stored in a CDN, theclient is provided with a so-called manifest file identifying a list ofsegment identifiers and segment locators pointing to locations in thenetwork, which enable the client to retrieve the segments. Typically, aclient is configured to retrieve segments such that the segment bufferassociated with the client (device) is loaded with a predeterminednumber of segments before play-out is started. Furthermore, duringplay-out, the client continuously retrieves segments on the basis of themanifest file so that sufficient segments are kept in a buffer. Thisway, latencies associated with segment retrieval do not interfere withthe seamless play-out of the segments.

In some cases however, a client may allow a user to interact with theplay-out of the content (e.g. fast-forwarding, panning, zooming and/ortilting). Further, a user may instruct a client to switch to anotherrate or video quality. In all of the above cases, play-out of a segmentmay be required that is not available in the buffer, so that the clientwill start retrieving that segment on the fly (from the CDN or othernetwork). This process however may take considerable time because thesegment needs to be located and retrieved using a resolving process,which may involve DNS look-ups and HTTP redirects. Moreover, in somecases (content) segments associated with a content item (e.g. avideo/movie) may be stored at (CDN/other network) nodes, which belong totwo or more different CDNs. In that case, no central location manager isavailable to locate the segments in the different CDN domains.Therefore, a manifest file associated with a first CDN may only refer toa routing function in the further CDNs as the first CDN has no knowledgeabout the location of the segments in the second CDN. Every time asegment from another (second) CDN is requested, a routing request tothat other (second) CDN is required. In addition, one or more furtherrouting requests (and responses) may be generated in the other (second)CDN. Such requests may generate request-routing delays so that its takesa longer time, up to several seconds, for a client to receive therequested segment.

Hence, from the above it follows that without any user interaction,delays associated with DNS request, redirections and/or inter-CDN(CDN-I) request routing will have little impact on the user perceptionof the quality of the (video) stream, as the client will typically havea few segments buffered, allowing for some slack. If however userinteraction with the (segmented) content is allowed, play-out of asegment that is not available in the buffer may take considerable timebecause the segment needs to be located using a resolving process. Thisprocess may take up to several seconds in case of complex orinterconnected CDNs so that seamless play-out of segmented (video)content is no longer possible and the user experience is seriouslydowngraded.

Hence, there is a need in the art for efficient streaming of segmentedcontent to a client. In particular, there is a need for methods andsystems providing seamless play-out of segmented content even in case auser interacts with the segmented content.

SUMMARY OF THE INVENTION

It is an object of the invention to reduce or eliminate at least one ofthe drawbacks known in the prior art and to provide in a first aspect ofthe invention to a method for enabling streaming, preferablyclient-controlled streaming, of segmented content on the basis of amanifest file for locating one or more delivery nodes wherein saidmethod may comprise at least one of the steps of: requesting thedelivery of at least one segment on the basis of said manifest file; onthe basis of a segment identifier associated with said segment request,selecting at least one further segment identifier from said manifestfile, said further segment identifier being associated with an expectedfuture segment request; and, pre-resolving at least part of a firstsegment locator associated with said selected further segment identifierfor obtaining network information associated with said first segmentlocator. In an embodiment, a manifest file may comprise one or moresegments identifiers and/or one or more associated segment locators. Inanother embodiment, a delivery node may be configured to deliver one ormore segments identified by said segment identifiers to said client. Inyet another embodiment, a segment locator may be a predetermined part ofan URL pointing to a network node.

Hence, the method allows a client to select segments, which are listedin a manifest file and which are expected to be requested in the future,and to at least partially pre-resolve one or more segment locatorsassociated with these selected segments on the basis of one or moresegments which are requested by the client. This way delays associatedwith request routing, DNS requests and/or redirects are eliminated or atleast substantially reduced so that seamless or at least substantiallyseamless play-out of segments during user interaction may be achieved.

In one embodiment, the network information may comprise: information onat least part of a network address associated with at least part of saidfirst segment locator; and/or, information whether a first segmentlocator associated with said selected further segment identifier pointsto a delivery node for delivery of a segment associated with saidexpected future segment request or points to a network node forredirection of said expected future segment request; and/or, at leastpart of a second segment locator associated with said selected furthersegment locator. In another embodiment, said method may comprise:pre-resolving at least part of said first segment locator into a secondsegment locator associated with said selected further segmentidentifier, if said first segment locator points to a network node forredirection. In a further embodiment, comprising: modifying saidmanifest file on the basis of said network information. Hence, on thebasis of the retrieved network information the manifest file stored in amanifest cache may be updated. This way the client, in particular thepre-resolving function associated with the client, may continuously anddynamically update the manifest file with fully and/or partiallypre-resolved segment locators.

In an embodiment, said method may comprise: modifying said manifest fileon the basis of said at least part of said second segment locator,preferably said modifying comprising the step of replacing at least partof said first segment locator with said at least part of said secondsegment locator. The result of the pre-resolving step may be used toreplay and/or modify the original segment locator into a furtherpartially pre-resolved segment locator so that when a segment associatedwith the partially pre-resolved segment locator is requested, the delayassociated with resolving the segment locator is substantially reduced.

In a further embodiment, said method may comprise: modifying saidmanifest file on the basis of said second segment locator, if saidsecond segment locator is associated with a network address of adelivery node for delivery of a segment associated with said expectedfuture segment request. The result of the pre-resolving step may be usedto replay and/or modify the original segment locator into a fullypre-resolved segment locator, so that when the segment is requestedresolution of the segment request is not needed.

In yet further embodiment, said method may comprise at least one of thesteps of: sending a request for network information to a network nodeassociated with said first segment locator; receiving a responsemessage; determining on the basis of said response message whether saidfirst segment locator associated with said selected further segmentidentifier points to a delivery node for delivery of a segmentassociated with said expected future segment request or to a networknode for redirection of said expected future segment request.

In yet another embodiment, said request for network information maycomprise an HTTP, RTSP and/or DNS protocol message, preferably an HTTPHEAD message or an RTSP DESCRIBE message and/or wherein said responsemessage is an HTTP or RTSP response message.

In an embodiment said pre-resolving may be executed as a backgroundprocess during at least part of the delivery of said at least onesegment.

In an embodiment, said method may comprise: selecting said at least onefurther segment identifier on the basis of at least part of: a userprofile, a user navigation history, user interaction with the segmentedcontent and/or the geo-location of the user. Hence, selection of thesegments associated with expected future segment requests may be basedon user-related information.

In an embodiment, said manifest file may comprise one or more markersfor marking one or more further segment identifiers for future segmentrequests, preferably said marker comprising a ranking value. This way,selection of the segments for pre-resolving may be based on informationin the manifest file. This information may be inserted into the manifestfile by a CDN or by a content provider.

In one variant, said pre-resolving may comprise at least one of thesteps of: transmitting a request for network information, preferably anHTTP HEAD message or an RTSP DESCRIBE message, to a first contentdelivery network (CDN1), said request comprising at least said selectedfurther segment identifier; said first content delivery network CDN1transmitting an inter-CDN request message, preferably an DELIVERYREQUEST message, comprising said selected further segment identifier, toa second content delivery network (CDN2) for negotiating future deliveryof said segment identified by said selected further segment identifier;and/or, said first content delivery network CDN1 receiving an inter-CDNresponse message, preferably a DELIVERY RESPONSE message, comprisinglocation information, preferably a network address or a segment locatorassociated with one or more delivery nodes in said second contentdelivery network CDN2, said one or more delivery nodes configured todeliver a segment identified by said selected further segment identifierto a client. Hence, during the pre-resolving process, a network node offirst CDN may recognize a request for network information associatedwith pre-resolving a segment locator and forward the request to anetwork node of a second CDN thereby improving the efficiency of thepre-resolving process.

In an embodiment, said inter-CDN request message may comprise a flagallowing said second content delivery network CDN2 to determine that theinter-CDN request message is associated with the pre-resolving of asegment locator.

In another embodiment said inter-CDN request message may be implementedon the basis of an HTTP HEAD message or an RTSP DESCRIBE message therebyallowing said second content delivery network CDN2 to determine that theinter-CDN message is associated with the pre-resolving of a segmentlocator.

In yet another embodiment, said manifest file may comprises firstlocation information, preferably a network address, associated with oneor more delivery nodes in a first content delivery network (CDN1) andsecond location information, preferably a network address, associatedwith one or more delivery nodes in a second content delivery network(CDN2).

In a further embodiment wherein said segmented content is temporallysegmented content and wherein said client uses a temporal proximityparameter defining a temporal distance so that one or more segmentidentifiers identifying temporal segments arranged within the temporalproximity distance from the temporal segment that is currently processedby the client, may be marked and/or selected for pre-resolving their oneor more associated segment locators; or,

wherein said segmented content is spatially segmented content andwherein said client uses a spatial proximity parameter defining aspatial distance so that one or more segment identifiers identifyingspatial segments arranged within the spatial proximity distance from thespatial segment that is currently processed by the client, may be markedand/or selected for pre-resolving their one or more associated segmentlocators; or,

wherein said segmented content is qualitatively segmented content andwherein said client uses a quality proximity parameter defining aquality distance so that one or more segment identifiers identifyingquality segments arranged within the quality proximity distance from thequality segment that is currently processed by the client, may be markedand/or selected for pre-resolving their one or more associated segmentlocators.

In a further aspect, the invention may relate to a client forclient-controlled streaming of segmented content hosted on one or moredelivery nodes in the network, said client comprising: a manifest cachefor storing at least part of a manifest file, said manifest filecomprising one or more segments identifiers and one or more associatedsegment locators, preferably on or more URLs, for locating one or moredelivery nodes configured to deliver one or more segments identified bysaid segment identifiers to said client; a segment retrieval functionfor requesting the delivery of at least one segment on the basis of atleast one segment identifier in said manifest file; a segment selectorconfigured for selecting on the basis said at least one segmentidentifier, at least one further segment identifier associated with atleast one expected future segment request; and, a pre-resolving functionfor pre-resolving at least part of a first segment locator associatedwith said at least one selected further segment identifiers forobtaining network information associated with said first segmentlocator.

In another aspect, the invention may relate to a network node for usewith a client according as described above, said network node beingassociated with a first content delivery network (CDN1) and configuredfor: receiving from a client a request for network informationassociated with a segment locator, preferably said request being basedon the basis of an HTTP HEAD message or an RTSP DESCRIBE message, saidsegment locator being associated with a segment identifier identifying asegment; transmitting an inter-CDN request message, preferably anDELIVERY REQUEST message, comprising at least part of said segmentlocator and/or segment identifier, to a second content delivery network(CDN2) for negotiating future delivery of said segment; wherein saidinter-CDN request message comprises a flag or wherein said inter-CDNrequest message is based on an HTTP HEAD message or an RTSP DESCRIBEmessage, said flag or HTTP HEAD message or an RTSP DESCRIBE messageallowing said second content delivery network CDN2 to determine thatsaid inter-CDN message is associated with the pre-resolving of a segmentlocator requested by said client.

In yet a further aspect, the invention may relate to a data structure,preferably a manifest file, for use in client as described above, saiddata structure comprising one or more segments identifiers and one ormore associated segment locators, preferably URLs, for locating one ormore delivery nodes configured to deliver one or more segmentsidentified by said segment identifiers to said client; said datastructure further comprising one or more markers associated with one ormore of said segment identifiers, said one or more markers allowing apre-resolving function in said client to select further segmentsidentifiers for a future segment request, preferably said one or moremarkers being associated with a ranking value, preferably a popularityscore.

The invention also relates to a computer program product comprisingsoftware code portions configured for, when run in the memory ofcomputer, executing at least one of the method steps as described above.

The invention will be further illustrated with reference to the attacheddrawings, which schematically will show embodiments according to theinvention. It will be understood that the invention is not in any wayrestricted to these specific embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B depict a conventional adaptive streaming client and amanifest file for use in such client.

FIG. 2 depicts a flow diagram segment retrieval and playout process forconventional an AS client.

FIG. 3 depicts a client according to one embodiment of the invention.

FIGS. 4A and 4B depict a CDN-based content delivery system and a flowdiagram associated with a pre-resolving process for resolving locationsin a CDN-based content delivery system according to one embodiment ofthe invention.

FIG. 5 depicts the retrieval of a pre-resolved segment according to oneembodiment of the invention.

FIG. 6 depicts a flow diagram associated with the segment pre-resolvingand retrieval processes executed by the client according to anembodiment of the invention.

FIG. 7 depicts an example of pre-resolving at least part of a manifestfile stored in a manifest cache of the client according to oneembodiment of the invention.

FIG. 8 depicts a flow diagram of a process for requesting and play-outof a manifest file wherein unresolved segment URLs in the manifest fileare pre-resolved.

FIG. 9 provides depicts a detailed flow diagram of process executed bythe pre-resolving function in a client according to an embodiment of theinvention.

FIG. 10 depicts the selection of suitable segments for pre-resolvingaccording to one embodiment of the invention.

FIG. 11 depicts the selection of suitable segments for pre-resolvingaccording to another embodiment of the invention.

FIG. 12 depicts the selection of suitable segments for pre-resolvingaccording to yet another embodiment of the invention.

FIG. 13 depicts at least part of a manifest file comprising segments,which are marked for pre-resolving according one embodiment of theinvention.

DETAILED DESCRIPTION

FIGS. 1A and 1B depict a conventional adaptive streaming (AS) client anda manifest file for use with such AS client respectively. The client 102may be hosted on a terminal (not shown), which is configured tocommunicate with one or more media servers in the network and to enablestreaming of content on the basis of an adaptive streaming protocol,e.g., such as Apple HTTP Live Streaming[http://tools.ieff.org/html/draft-pantos-http-live-streaming-07],Microsoft Smooth Streaming[http://www.iis.net/download/SmoothStreaming], Adobe HTTP DynamicStreaming [http://www.adobe.com/products/httpdynamicstreaming],3GPP-DASH [TS 26.247 Transparent end-to-end Packet-switched StreamingService (PSS); Progressive Download and Dynamic Adaptive Streaming overHTTP] and MPEG Dynamic Adaptive Streaming over HTTP [MPEG DASH ISO/IEC23001-6].

The terminal may generally relate to a content processing device, e.g. a(mobile) content play-out device such as an electronic tablet, asmart-phone, a notebook, a media player, etc. In some embodiment, aterminal may be a set-top box or content storage device configured forprocessing and temporarily storing content for future consumption by acontent play-out device.

A user may connect a terminal to a network, e.g. the Internet, browse awebsite of a content provider comprising video title links and selectone. Upon selection of a link, e.g. an URL, a so-called manifest filemay be sent to the client. Here, the term manifest file may generallyrefer to a special data structure comprising segment identifiers(descriptors) identifying the segments building the video title,location information of a (set of) network node(s), e.g. mediaserver(s), which may be configured to either deliver the segments to theclient or to provide the client with information where the segments maybe retrieved and, optionally, segment control information determiningthe relation between the segments which may be used by the client tocorrectly determine a sequence of segments for play-out. Differentprotocols may use different names for a manifest file. For example, inthe DASH streaming protocol a manifest file may be referred to as amedia presentation description (MPD).

FIG. 1B depicts a schematic of a manifest file comprising segmentidentifiers for identifying segments building a content item andlocation information comprising references to one or more network nodeswhich are configured to deliver the identified segments to a client orwhich are configured to provide the client with information where thesegments may be retrieved. Hence, such reference, which hereafter may bereferred to as segment locator, may point to a network node configuredto deliver an identified segment; or, alternatively, to a network nodethat is able to determine one or more network nodes which may be able todeliver an identified segment. In yet another embodiment, a segmentlocator may also point to location on a network node. For example,different segment locators may point to different folders defined in onedelivery node.

FIG. 1B depicts a schematic of a manifest file which is used by theclient to locate delivery nodes configured to deliver segmentsidentified in the manifest file to the client. To that end, the manifestfile may comprise at least one segment identifier, e.g. a segment filename, for identifying a segment and location information in the form ofat least one segment locator associated with a segment identifier. Asegment locator may be defined as a pointer to one or more network nodes(or one or more folders on a network node) which are configured to hostthe identified segment and to deliver the segment to a client or whichare configured to determine one or more further network nodes which maybe able to deliver the identified segment to the client.

In some embodiments, a segment identifier and a segment locator may bepart of a predetermined data structure such as an URL. For example, theURL central.cdnA.com/segment1-1.avi comprises a segment locatorcentral.cdnA.com, i.e. a pointer (or a reference) to a network node ofCDN A and a segment identifier, i.e. segment file name segment1-1.aviwherein the network node associated with segment locatorcentral.cdnA.com may be configured to deliver a segment to the client ormay be configured to deliver one or more further segment locatorspointing to one or more network nodes which may be able to deliver thesegment segment1-1.avi. Although the examples hereunder are describedusing URLs, it is submitted that the invention is not limited thereto.In another embodiment, the segment identifiers and segment locators maytake any suitable format suitable for identifying and locating segmentsin the network. In some embodiments, the segment identifier and thesegment locator may coincide in the sense that either the segmentidentifier or the segment locator may be used for identifying andlocating a segment in the network.

In the example of FIG. 1B, the manifest file comprises segmentidentifiers and segment locators associated with two different sets ofsegments, i.e. a first set of low bitrate segments and a second set ofhigh-bitrate segments, wherein each set contains the video title. Here,the segment locator part of the URLs associated with the low-bitratesegments points to a network node of a first content delivery networkCDN A and the high-bitrate segments points to a network node of a secondCDN B. The client may retrieve segments on the basis of the segment URLsin the manifest file. This scheme is described hereunder in more detail.

As illustrated in FIG. 1A, the manifest file may be stored in a manifestcache 104 and parsed and structured into a segment list, i.e. a logicaldata structure, comprising information for retrieving segments, e.g.segment identifiers (e.g. the segments file names) and segment locators,e.g. a predetermined parts of URL(s), for determining where thesesegments may be retrieved, and play-out control information forcontrolling the play-out of the segments, i.e. the relation between thesegments (e.g. time relationship, quality relationship and/or spatialrelationship).

A segment retrieval function 106 may use the location information in themanifest cache in order to retrieve segments from a media server or oneor more delivery nodes associated with a content delivery network (CDN).The segments may be retrieved using a (segment) transfer protocol(typically this would be HTTP, but also RTSP/RTP, FTP and otherprotocols could be used) and temporarily stored into a segment buffer108. Further, a video play-out function 110 (which may also referred toas the media engine) may play-out segments stored in the segment bufferon the basis of the information in the manifest cache.

The segment retrieval function may be configured to retrieve segmentssuch that the segment buffer is loaded with a predetermined number ofsegments before play-out is started. Furthermore, during play-out, thesegment retrieval function continuously retrieves segments on the basisof the manifest file so that sufficient segments are stored in thesegment buffer. This way, latencies associated with segment retrieval donot interfere with the seamless play-out of the segments. The segmentretrieval function may accept and handle segment retrieval instructionsfrom the user navigation function 112 so that a user is able to navigatethrough the segmented content as defined by the manifest file. Here, thesegment retrieval instructions from the user navigation function mayrelate to temporal navigation (e.g. fast forwarding) or spatialnavigation (e.g. panning-zooming-tilting).

One problem related to the conventional AS client as depicted in FIG. 1Arelates to the fact that if the user navigation function requiresplay-out of a segment that is not available in the segment buffer, thesegment retrieval function will start retrieving the required segment onthe fly. This process however may take considerable time because thesegment needs to be located using a resolving process in which an(unresolved) segment locator in the manifest file is resolved into anetwork address associated with a network node hosting the segment. Thisresolving process may involve DNS look-ups, HTTP redirects and/or interCDN (CDN-I) request routing. This process may take up to several secondsin case of complex or interconnected CDNs. The process of downloadingthe segment may also take significant time. However, as the play-outprocess may already start before the whole segment has been downloaded,the quality of experience as perceived by the user when navigatingthrough the content is mainly determined by the segment resolvingprocess.

FIG. 2 depicts the segment retrieval and play-out process of aconventional client as depicted in FIG. 1A in more detail. The processmay start at t=0 at which the client may start playing out bufferedsegments, in this case a first segment “segment1-1.avi” (step 200),which were previously retrieved from a CDN by the segment retrievalfunction on the basis of a manifest file as explained with reference toFIGS. 1A and 1B. Once the play-out of the first segment is finished,subsequent segments at t=1 (segment1-2.avi) and t=2 (segment1-3.avi) maybe processed and played-out.

Then, at t=2, during play-out of a segment with segment file namesegment1-3.avi, the user may interact with the content using the usernavigation function in the client (for example by selecting a button togo into a low bitrate play-out mode). The result of the interaction maybe that a new segment, i.e. low bitrate segment2-4.avi, is required thatis not available in the segment buffer of the terminal (step 202).

When the client determines that the segment is not available in thebuffer, it may trigger the segment retrieval function to retrieve thelocation information, e.g. a segment locators, of the low-bitratesegment segment2-4.avi in the manifest file and resolve the segmentlocator central.cdnA.com by sending a DNS request message comprising thesegment locator associated with a request routing function of CDN Acentral.cdnA.com to a DNS system, which may send a DNS response messagecomprising a resolved IP address back to the client (steps 204, 206). Inresponse, the client may send a HTTP GET request for segmentsegment2-4.avi to the DNS resolved IP address 123.45.67.89 (step 208) ofthe request routing node of CDN A. In response to the request, CDN A, anupstream CDN, may consult with CDN B, a downstream CDN, about deliveryof the requested segment (steps 210, 212).

Here, communication between CDN A and CDN B may be based on the CDNIRequest Routing (RR) interface as described indraft-ietf-cdni-problem-statement-01. This interface allows the requestrouting nodes in interconnected CDNs to communicate to ensure that auser request may be (re)directed from an upstream CDN (in this case CDNB) to a surrogate in the downstream CDN. The CDNI RR interface may allowthe downstream CDN to provide to the upstream CDN with information (e.g.resources, footprint, load) to facilitate selection of the downstreamCDN by the upstream CDN request routing system when processing contentrequests.

After the inter-CDN consultation, the request routing node of CDN A maydetermine that the delivery of the segment for this particular user isbest served by CDN B. The request routing function of CDN A maytherefore send a HTTP redirect response containing location informationof the request routing node of CDN B (central.cdnB.com/segment2-4.avi)back to the client (step 214). Upon receiving the HTTP redirect, theclient performs another DNS query and sends a new HTTP GET to theresolved IP address 98.65.45.201 of the request routing node of CDN B(step 216-220).

Thereafter, the request node of CDN B, in particular the CDN controlfunction (CDNCF) of CDN B, may decide on the delivery node (DN) bestsuited to deliver the particular segment to the client (steps 222, 224)and send a HTTP redirect containing a segment locator (in this casenode3.cdnB.com) back to the client. The client may thereafter performanother DNS query in order to retrieve the IP address 24.67.13.57 of thedelivery node. The client then sends an HTTP GET comprising the URL24.67.13.57/segment2-4.avi to the thus resolved IP address of thedelivery node (step 228-232), which in response sends the requestedsegment (segment2-4.avi) to the client (step 234). Then at t=9 theclient may receive segment2-4.avi and start play-out.

Hence, as can be seen from FIG. 2, without user interaction, redirectionand request routing delays have little effect on the user perception, asa client will typically buffer a few segments before starting play-out.However, when user interaction with a client is allowed, the client hasno knowledge which segment the user will select. As illustrated in FIG.2, temporal (fast forwarding), spatial (panning/zooming) or switching toanother rate in a multi-rate scheme requires ad hoc segment retrieval,which may take considerable latencies. For example, in FIG. 2 betweenthe user interaction at t=2 and the reception of the segment associatedwith that user action at t=9, latencies up to several seconds in orderto perform all protocol exchanges (DNS, HTTP redirection and inter CDNsignalling) are possible. Such latencies will interrupt seamlessplay-out of the segments thereby spoiling the user experience.

FIG. 3 depicts a client according to one embodiment of the invention. Inparticular, FIG. 3 depicts an AS client comprising a pre-resolvingfunction 314 which is configured to pre-resolve a segment locator, e.g.at least part of an URL, of a segment that is expected to be selected bythe client for playout in the near future.

In order to predict such segments, a segment selector 313 may use usernavigation information from the user navigation function 312 in order toselect at least one segment from the segment list stored in the manifestcase 304. This process will described hereunder in more detail. Theclient may further comprise a segment retrieval function 306, a segmentbuffer 308 and a video play-out function 310 (media engine) similar tothose described with reference to FIG. 1.

On the basis of the segment that is played-out and on the basis of theuser navigation information provided by the user navigation function,the segment selector may predict which segment(s) is(are) most likely tobe selected by the client in the near future. The user navigationinformation thus provides contextual information, i.e. information thatis user-specific (e.g. the user profile, the user navigation history,the (geo)location of the user, etc.), which is used by the segmentselector for predicting future segment play-out.

The pre-resolving function may also use general navigation informationassociated with the played segmented content, e.g. information regardingfrequently requested segments associated with a particular content item.This general navigation information may be used together with the usernavigation information in order to predict future segment play-out. Inone embodiment, a content provider or a control function in the CDN mayinsert general content navigation information in the manifest file (e.g.segments that are marked as popular) when it is delivered to a client.This embodiment is described in more detail with reference to FIG. 13.In another embodiment, the pre-resolving function may receive generalnavigation information via another communication channel from thecontent provider, the CDN or a third party.

If the predicted segment(s) is(are) not in the segment cache, thepre-resolving function may start a pre-resolving process wherein thesegment locators of predicted segments are fully or at least partiallypre-resolved, without actually retrieving the predicted segments. Here,the term pre-resolving refers to a process for obtaining networkinformation associated with a segment locator of a predicted segment.Network information may include an IP address, (part of) a furthersegment locator and/or information whether a segment locator points to anetwork node which is configured to deliver a segment to a client (i.e.a delivery node) or to redirect requests for network information. Thisprocess of pre-resolving segment locators of predicted segments may beexecuted in parallel (or as a background process) with the playout ofsegments and may use techniques such as DNS look-ups, redirects and/orinter-CDN request routing without actually retrieving the segments.

The network information associated with a segment locator may be used tomodify a manifest file in the client. For example, in one embodiment, ifthe process of pre-resolving a segment locator of a predicted segmentresults in a fully pre-resolved segment locator, i.e. a segment locatorpointing to a network address of a delivery node configured to deliver asegment to a client, the pre-resolving function may receive thepre-resolved network address and use this network address to modify orrewrite entries in segment list stored in the manifest cache 304.Alternatively, the pre-resolving function may add the resolved networkaddress to the segment list. Further, if the pre-resolving process of asegment locator of a predicted segment results in a partiallypre-resolved segment locator, i.e. a further, second segment locator(which needs one or more further pre-resolving steps in order to resolveit into a fully pre-resolved segment locator), the pre-resolvingfunction may use this partially pre-resolved segment locator to update,e.g. modify or rewrite, entries in segment list stored in the manifestcache 304.

This way, when a fully or partially pre-resolved segment is selected bythe user via the user navigation function, the client may skip all or atleast part of the resolving steps described with reference to FIG. 2,thereby considerably reducing the retrieval time of a predicted segment.Especially, if the segment locator is fully pre-resolved the client mayretrieve with a minimal request routing delay the segments on the basisof the pre-resolved network address stored in the manifest cache, whichwas determined earlier by the pre-resolving function.

FIG. 4A depicts a content streaming system according one embodiment ofthe invention. In particular, FIG. 4A illustrates a CDN-based contentdelivery system comprising a first CDN 402 (also referred to as theupstream CDN) interconnected via an CDN interconnect interface 464 to atleast a second CDN 404 (also referred to as the downstream CDN).

The content delivery system may further comprise a content source 406connected via a transport network 407 to one or more terminals 408hosting a client. The content source may relate to a content providersystem CPS, a content preparation system or another CDN. A CPS may beconfigured to offer content, e.g. a video title, to customers, which maypurchase and receive the content using an AS client as described withreference to FIG. 3 for video play-out.

A CDN may comprise delivery nodes 410, 413, 414 and at least one centralCDN node 416, 418. Each delivery node may comprise or be associated witha controller 420, 422, 424 and a cache 440, 442, 444 for storing andbuffering content. Each central CDN node may comprise or may beassociated with an ingestion node (or content origin function, COF) 425,427 for controlling ingestion of content from an external source, e.g. acontent provider or another CDN, a content location database 434, 436for maintaining information about where content is stored within a CDNand a CDN control function (CDNCF) 426, 428 for controlling thedistribution of one or more copies of the content to the delivery nodesand for redirecting clients to appropriate delivery nodes (a processalso known as request routing). In one embodiment, the node hosting theCDNCF may be referred to as the request routing (RR) node. A customermay purchase content, e.g. video titles, from a CPS 430 by sending arequest to a web portal (WP) 432, which is configured to provide titlereferences identifying purchasable content items. The CDNCF may managethe locations where segments may be retrieved using the content locationdatabase 434, 436.

In the content delivery system of FIG. 4A, the upstream CDN mayoutsource part of the delivery of segments to a client to the downstreamCDN. For example, in one embodiment, low-quality segments may be locatedand delivered by a first CDN A (configured e.g. for delivery of contentto mobile devices) and high quality segments may be located anddelivered by a second CDN B (configured e.g. for delivery ofhigh-quality segments to home media devices supporting HDTV technology).

FIG. 4B depicts a flow diagram associated with a pre-resolving processaccording to on embodiment of the invention. In particular, FIG. 4Bdepicts a flow diagram of an HTTP-based pre-resolving process whereinthe HTTP HEAD message is used.

At t=2, during buffering and play-out of segments by the client, a usermay interact with the content using the user navigation function in theclient (for example by pressing a button to perform a panningoperation). During the interaction, the segment selector may determine(predict) that it is highly likely that a particular segment in themanifest file, segment2-4.avi, may be requested by the play-out functionin the near future and that the segment associated with such request iscurrently not available in the segment buffer of the terminal. Suchsegment request may be referred to as an expected future segmentrequest.

When it is determined that this predicted segment is not available inthe segment buffer, the client may decide to partially or fullypre-resolve the (unresolved) segment locator of the predicted segment byrequesting network information associated with a segment locator fromthe network (step 452).

On the basis of this network information, the pre-resolving function maye.g. modify the segment locator (in this case part of the URL pointingto a request routing node central.cdnA.com) into a further segmentlocator. Such further segment locator may relate to partiallypre-resolved segment locator or a fully pre-resolved segment locatorcomprising a network address, e.g. an IP address, associated with atleast one delivery node configured to deliver this segment to theclient. This process of pre-resolving segment locators will be describedhereunder in more detail.

The pre-resolving process may start by sending a DNS request messagecomprising part of an URL (central.cdnA.com) associated with of anetwork node, e.g. a network node comprising a request routing functionof CDN A, to a resolving function in the network, e.g. DNS system, andreceive a response message comprising an IP address of the network node,in this case a network node comprising a request routing functionassociated with CDN A (steps 454, 456). Further, the client may checkwhether this network node is able to deliver the predicted segment. Tothat end, it may send a HTTP HEAD request for segment segment2-4.avi tothe DNS-resolved IP address 123.45.67.89 (step 458). If this networknode is able to deliver the requested segment, it may respond to therequest with an HTTP 200 OK message. If it is not able to deliver therequested segment, it may respond with a HTTP REDIRECT messagecomprising a further segment locator, which needs to be pre-resolvedfurther in order to obtain the network address of the network node whichis configured to deliver the requested segment to the client. As alreadymentioned earlier, such further segment locator may hereafter bereferred to a partially pre-resolved segment locator.

Hence, when receiving the HTTP HEAD request message, the request routingfunction in CDN A may consult with CDN B over the CDNI Request Routing(RR) interface about delivery of the requested segment (steps 460, 462).

In one embodiment, before redirecting the client to CDN B, the RR nodeof CDN A may request confirmation that CDN B is capable and willing todelivery a particular segment to a client. In that case, it may send aninter-CDN message, e.g. an DELIVERY REQUEST message, to the RR node ofCDN B, wherein the request may comprise a parameter identifying therequested segment and location information, e.g. the IP address of theclient. The DELIVERY REQUEST may be implemented with a HTTP GET message.

In another embodiment, the inter-CDN message, e.g. an HTTP GET DELIVERYREQUEST message, sent by the RR node of CDN A to the RR node of CDN B,may include a flag indicating that the particular inter-CDN message doesnot relate to an actual content request by a client (e.g. an HTTP GETmessage) but to a pre-resolving step performed by a client (e.g. on thebasis of an HTTP HEAD message). The flag may be used to inform the RRnode of CDN B the nature of the request, allowing it to select anappropriate follow-up action (for the purpose of charging, statistics,etc.).

In another embodiment, if the inter-CDN message, e.g. the DELIVERYREQUEST, is related to a pre-resolving step instead of a contentrequest, the inter-CDN message may be implemented with an HTTP HEADmessage instead of an HTTP GET message so that the RR node of CDN Bknows the nature of the request allowing it to select an appropriatefollow-up action (for the purpose of charging, statistics, etc.). Inthis embodiment, in response to the HTTP HEAD message, the HTTP 200 OKresponse message may comprise the requested segment and locationinformation, e.g. the IP address of the client, in its header (asresponse messages to an HTTP HEAD request do not have a body).

After consultation with CDN B, the request routing node of CDN A maydetermine that the delivery of this particular segment to thisparticular user is best served by CDN B. It therefore may send a HTTP302 REDIRECT response comprising a partially resolved segment locator,i.e. part of the URL pointing to the request routing node of CDN B(central.cdnB.com), back to the client (step 464). Messages send inresponse to an HTTP HEAD message do not comprise a body, hence the HTTP302 REDIRECT message also does not comprise a body. This is however nota problem, as the redirect information, including the partially resolvedsegment locator, may be contained in its header so that no message bodyis required.

Upon reception of the HTTP REDIRECT message comprising the partiallyresolved segment locator, the client may determine that the segmentlocator in the request has not been fully pre-resolved into a networkaddress. The pre-resolving function may then decide to stop thepre-resolving process and rewrite part of the manifest file in themanifest cache by replacing the original segment locatorcentral.cdnA.com with a partially pre-resolved segment locatorcentral.cdnB.com (not shown in FIG. 4B).

Alternatively, upon receiving the HTTP redirect, the AS client maydecide to continue the pre-resolving process by performing another DNSquery (steps 466, 468) and send a new HTTP HEAD to the resolved IPaddress 98.65.45.210 of the request routing node of CDN B (step 470).

Thereafter, the request node of CDN B, in particular the CDN controlfunction (CDNCF) of CDN B, may decide on the delivery node (DN), whichis best suited to deliver the particular segment to the client (steps472, 474) and send a HTTP redirect containing the location of theselected delivery node (step 476), in this case segment locatornode3.cdnB.com, back to the client. Upon reception of the HTTP REDIRECTmessage, the client may again determine to either stop the pre-resolvingprocess by and rewrite part of the manifest file in the manifest cacheby replacing the original segment locator central.cdnA.com with apartially pre-resolved segment locator node3.cdnB.com (resulting in amodified URL node3.cdnB.com/segment2-4.avi) (not shown in FIG. 4B); or,to continue the pre-resolving process.

The client may continue the pre-resolving process by performing anotherDNS query (steps 478, 480) in order to resolve the URL into a networkaddress of the delivery node (in this case IP address 24.67.13.57)configured to deliver this segment to the client. Also, at this point,the pre-resolving function may decide to stop the pre-resolving processand to store the result, i.e. the segment locator 24.67.13.57, into themanifest cache (not shown).

If the pre-resolving function continues the pre-resolving process, thepre-resolving function again may check whether the network nodeassociated with the pre-resolved segment locator is able to deliver thepredicted segment. To that end, it may send an HTTP HEAD to the networkaddress of the delivery node (step 482), which in response sends an HTTP200 OK message confirming the pre-resolving function that thepre-resolving process fully resolved the earlier segment locator (i.e.the one used at the start or at an intermediate stage in thepre-resolving process). This way it can be determined that the segmentmay be retrieved on the basis of the URL 24.67.13.57/segment2-4.avi(step 484).

Then, at t=9 the pre-resolving function may rewrite part of the manifestfile in the manifest cache by replacing the original segment locatorcentral.cdnA.com with the fully pre-resolved segment locator 24.67.13.57(resulting in the fully resolved URL 24.67.13.57/segment2-4.avi (step486). A flag or an indicator associated a segment locator may indicatewhether a segment locator is fully pre-resolved or partiallypre-resolved. The above-described process may be repeated for othersegments, wherein the user navigation information determines whichsubsequent segments may be partially or fully pre-resolved.

Hence, as can be derived from above, the pre-resolving function, whichpartially or fully pre-resolves predetermined segment locators in themanifest file in the manifest cache of the AS client on the basis ofnetwork information associated with a segment locator. In order toobtain such network information, the pre-resolving function may usepredetermined protocol messages, such as a DNS request or the HTTP HEADrequest as standardized in RFC2616. The HEAD request is identical to theHTTP GET requests except that a network node only returns the messageheader of a response. By sending a HEAD request to an URL found in themanifest file, the AS client may check on the basis of the responsemessage whether or not the URL hosts the actual segment. If the HTTPHEAD request returns an HTTP OK response, the AS client knows that theURL is the final destination and does not need to anticipate furtherrequest routing delays. If the response of the server is a HTTP REDIRECTmessage, it may stop the pre-resolving process at that point and replacethe unresolved segment URL with a partially resolved segment URL.Alternatively, the client may determine to continue the pre-resolvingprocess by sending another HTTP HEAD request to the URL listed in theredirect message. This process may be repeated until the final fullypre-resolved URL is received. It may then replace the URL stored in themanifest cache with the URL obtained by the pre-resolving process.

Although the process depicted in FIG. 4B is described with reference tothe HTTP protocol, it is not limited thereto. For example, if a manifestfile comprises one or ore RTSP segment locators, e.g. RTSP URLs, theclient may perform pre-resolving of segment locators using the RTSPDESCRIBE request. Further, in RTSP redirects may be handled in the sameway as HTTP by using 3xx response codes in the response. Hence, when aclient receives a 3xx response in response to an RTSP DESCRIBE, theclient knows that it has to send another RTSP DESCRIBE request to theURL in the 3xx response.

FIG. 5 depicts the retrieval of a segment on the basis of a pre-resolvedsegment locator according to one embodiment of the invention. In thisparticular example, the process may start in a same way as the processdescribed with reference to FIG. 2, i.e. the play-out of bufferedsegments, wherein the segment buffers is continuously filled withfurther segments by the segment retrieval function, which may beexecuted in parallel with the segment play-out process. Meanwhile, apre-resolving process as depicted in FIG. 4 is executed in the client asa background process so that segment locators in the manifest file,including the segment locator central.cdnA.com, are pre-resolved on thebasis of the user navigation information as explained with reference toFIG. 3.

Hence, as shown in FIG. 5, at t=0, the client may start playing outsegments (in this case segment1-1.avi; for sake of simplicity thesegment retrieval process is not shown in this figure) (step 500). Oncethe play-out of the first segment is finished, subsequent segments att=1 (segment1-2.avi) and t=2 (segment1-3.avi) may be processed andplayed-out. Then, at t=2, when the client is playing out segment1-3.avi,the user may interact with the content (for example by pressing a buttonto perform a panning operation) wherein the result of the interaction isthat a new segment segment2-4.avi is required.

As the segment locator associated with this segment was already fullypre-resolved by the pre-resolving function running in the background,the client may transmit an HTTP GET to the address of the delivery nodewherein the HTTP GET message comprises the segment identifiersegment2-4.avi (step 532). The delivery node at CDN B may respond bysending the requested segment segment2-4.avi in an HTTP 200 OK responsemessage to the client (step 534). Then, at t=4 the client startsreceiving and playing segment2-4.avi (step 536).

As can be seen from FIG. 5, the pre-resolving function in the clientsignificantly reduces delays introduced by the segment retrieval processupon user interaction with the content. In case a segment is onlypartially pre-resolved, the unfinished part of the pre-resolving processneeds to be finished before the segment can be retrieved. Nevertheless,also in that case (especially with a large numbers of segments need tobe pre-resolved) considerable improvements in reducing the requestrouting delays may be achieved. This way, perceived quality ofexperience by the user when navigating through the content may beconsiderably improved. Further, the pre-resolving function may be usedwith existing network technology only requiring an updated in the clientsoftware.

FIG. 6 depicts a flow diagram associated with the pre-resolving andsegment retrieval processes executed by the client according to anembodiment of the invention. At some moment, while browsing on awebsite, a user select on a link to a web video. Upon selection theuser's client may sends a HTTP GET request to the URL contained in thelink. In this case the link points to a manifest file named manifest.mfon the request routing node of CDN A (step 600). Upon reception of theclient's request for the manifest file, the request routing node maydetermine which delivery node is best suited to deliver the manifestfile to the client. It may then send an HTTP REDIRECT message to theclient containing the URL of the chosen delivery node (step 601). Oncethe client receives the HTTP REDIRECT message, it may send a new HTTPGET to the URL contained in the REDIRECT message (in this case the URLnode1.cdnA.com/manifest.mf)(step 602). The CDN A delivery node mayrespond by sending the requested manifest file to the client (step 603).

Upon receiving the manifest file, the client may parse the manifest fileto get an idea of the structure of the content described by it (step604). After parsing the manifest file, the client process splits into(at least) two separate processes (threads): a first process forrequesting and playing out segments (first process 607) as describedwith reference to FIG. 5 and second (background) process forpre-resolving segment locators associated with segments as selected bythe segment selector (second process 606) as described with reference toFIG. 3-4.

These message flows clearly illustrate that once segment locators arepre-resolved, no further redirection is necessary, since the client canimmediately contact the server hosting the segments on the basis of thepre-resolved network addresses in the manifest cache. It also shows thatefficient retrieval of segments may be achieved even if differentsegments are located on different nodes and even in different CDNs.

FIG. 7 depicts an example of pre-resolving segment locators of at leastpart of a manifest file according to one embodiment of the invention. Inparticular, FIG. 7 depicts an example of how a client uses apre-resolving process in order to replace segment locators, e.g.predetermined parts of URLs stored in the manifest cache of a terminal,wherein segment locators to be pre-resolved are selected by a segmentselector on the basis of user navigation information and contentnavigation information (as described with reference to FIG. 3).

A first manifest file 700 may be received by the client from a CDN asdescribed with reference to FIG. 6. In this case, the manifest filerefers to a number of so-called spatial segment files, which may be usedto stream spatially segmented content to a client.

Spatially segmented content or tiled content is used in a so-calledtiled video system wherein multiple resolution layers of a video contentfile may be generated. An example of a tiled video system is describedin Mavlankar et al. “An interactive region-of-interest video streamingsystem for online lecturing viewing”, proceeding of ICIP 2010, p.4437-4440.

Spatially segmented content may be generated by spatially dividing videoframes in a video file into so-called tiles, wherein each tile comprisescontent associated with a spatial region of the original video framefrom which the tile is generated from. On the basis of sequences ofvideo frames, sequences of tiles associated one spatial region may begenerated and formatted as a separate stream, e.g. an MPEG stream. Suchstream may be referred to as a spatial segment stream or—in short—aspatial segment.

Hence, spatial steams are encoded and distributed (i.e. streamed)independently from each other. A video client in a terminal may requesta specific spatial region, a Region of Interest (ROI), and a server maysubsequently map the ROI request to one or more spatial segments andtransmit a selected group of spatial segments to the client, which isconfigured to combine the spatial segment streams into one seamlessvideo. Segmented content is described in more detail with reference toFIG. 10-12.

The manifest file in FIG. 7 indicates that the spatially segmentedcontent was generated on the basis of a content source file Movie_4 andthat four separate spatial segment streams defined by segmentidentifiers (file names) Movie-4-1.seg, Movie-4-2.seg, Movie-4-3.seg andMovie-4-4.seg are stored within the domain of CND A wherein apredetermined part of the URLs central.cdn_A.com (701 a-701 d) points toa general Request Routing node within the CDN A. Hence, these segmentlocators are unresolved in the sense that do not comprise the networkaddress of the nodes where a segment may be retrieved. When thismanifest file is used by the client in a streaming process, apre-resolving process may be used as described in detail with referenceto FIG. 4.

During that process, at least part of the unresolved segment locatorcentral.cdn_A.com in the URLs 701 a-701 d associated with the foursegments may be replaced by a network address. This way four resolvedURLs 703 a-703 d may be formed each comprising the network address ofthe delivery node where these segments may be retrieved. The resolvedURLs may point to e.g. one or more delivery nodes, some of which may belocated in e.g. a further CDN B. As can be seen in FIG. 7, the segmentsmay all be retrieved from one delivery node identified by networkaddress 24.67.13.57.

FIG. 8 depicts a flow diagram of a process for requesting and play-outof a manifest file wherein unresolved segment locators are at leastpartially pre-resolved. The process may start with a client requestingthe manifest file associated with the desired content (step 800). Inresponse to the request, the client may receive the manifest file from aserver (step 801) and start play-out of the video by requesting thefirst segments listed in the manifest file (step 802).

During play-out, user interaction is analysed by the segment selector topredict which segments and associated segment locators the user willprobably require in the near future (step 803). These predicted segmentlocators are then marked by the segment selector for (partial)pre-resolving. The pre-resolving function may then partially or fullypre-resolve the segment locators marked for pre-resolving (step 804). Ifthe last segment locator is processed (step 805), the process isstopped. If not, a new round of pre-resolving starts.

FIG. 9 depicts a detailed flow diagram of a pre-resolving processaccording to an embodiment of the invention. In particular, FIG. 9depicts a flow diagram of a pre-resolving process wherein segmentslocators in a manifest file are pre-resolved on the basis of networkinformation associated with these segment locators.

In a first step 900, the pre-resolving function may receive a list ofsegment locators, e.g. URLs, that need to be partially or fullypre-resolved, wherein each segment associated with a segment locator isidentified by a particular segment identifier, e.g. a segment file name.This list may be generated during step 803 in the process described withreference to FIG. 8.

The pre-resolving function may fetch the first segment locator, e.g. apredetermined part of an URL pointing to a network node, from the listof segment locators needed to be resolved (step 901) and start obtainingnetwork information associated with the segment locator (step 902). Thenetwork information may be obtained using one or more request messagesfor network information as described e.g. with reference to FIG. 4B.These message may include: one or more DNS messages (e.g. a DNS query);and/or, one or more request messages for determining whether a segmentlocator points to a network node for delivery of a segment or forredirection of a request (e.g. an HTTP HEAD or an RTSP DESCRIBEmessage); and/or one or more response messages indicating whether asegment locator points to a network node for delivery of a segment (adelivery node) or to a network node for redirection of a request (e.g.an HTTP 200 OK message or an 3xx RTSP error message).

On the basis of these messages, the pre-resolving function may use thenetwork information to update the segment locator (step 903). If on thebasis of the network information it is established that the updatedsegment locator points to a delivery node for delivering a segmentassociated with the segment locator (step 904) (because e.g. an HTTP 200OK message was received), the pre-resolving function may determine thatthe updated segment locator is a fully pre-resolved segment locater(step 905). The pre-resolving function may further update the segmentlist by replacing the initial segment locater in the manifest list withthe fully pre-resolved segment locator (step 906). Optionally, a flag orindicator may be used to signal the client that the thus modifiedsegment locator relates to a fully pre-resolved segment locator.

If on the basis of the network information, it is established that theupdated segment locator is not pointing to a delivery node, but e.g. toa node for redirection (because e.g. a HTTP REDIRECT was received), thepre-resolving function may determine whether or not to stop thepre-resolving process (step 907). If the pre-resolving function decidesto continue the pre-resolving process (step 908), a process to obtainnetwork information is started (see step 902). If it is decided to stopthe pre-resolving process, the pre-resolving function may determine thatthe updated segment locater is a partially resolved segment locator(step 909). The pre-resolving function may further update the segmentlist by replacing the initial segment locater in the manifest list withat least part of the partially pre-resolved segment locator (step 910).Optionally, a flag or indicator may be used to indicate the client thatthe thus modified segment locator relates to a fully pre-resolvedsegment locator.

After, the update of the segment list, the pre-resolving function maydetermine whether further segment locators need to be pre-resolved (step911). If this is the case, the pre-resolving function may start thepre-resolving process on the basis of the next segment locator (step912).

This pre-resolving process may be executed at the background during theretrieving of segments from the network. This way, the segment list iscontinuously and dynamically updated with fully and/or partiallypre-resolved segment locators wherein segments locators to bepre-resolved are selected by the segment selector on the basis ofpredetermined information, e.g. user-related information such as a userprofile, the user navigation history and/or the geo-location of theuser; or, e.g. information in the manifest file such as a segment markerfor marking a particular segment locator identified in the manifest fileso that the pre-resolving function is able to select the marked segmentlocator for pre-resolving.

FIG. 10 depicts the selection of suitable segments locators forpre-resolving according to one embodiment of the invention. Inparticular, FIG. 10 depicts a simple algorithm for the segment selectorto determine which segments locators in a manifest file associated witha temporally segmented video, e.g. a HAS-based video stream, aresuitable for pre-resolving. In this case, the segments 1001 that aretemporally close to the segment 1000 currently being watched aresuitable for pre-resolving. Temporal segments that are located furtherfar away in time (1002) from the segment currently being watched are not(yet) suitable for pre-resolving. In one embodiment, the client may usea temporal proximity parameter defining a temporal distance. Thetemporal proximity parameter may be used for determining which segmentsidentified in the manifest file are in close temporal proximity to thesegment currently being played-out by the client. Segments identified inthe manifest file, which are fall within that temporal distance may bemarked for pre-resolving.

FIG. 11 depicts the selection of suitable segments locators forpre-resolving according to another embodiment of the invention. Inparticular, FIG. 11 depicts a simple algorithm for the segment selectorto determine which segments locators in a manifest file associated witha qualitatively segmented video are suitable for pre-resolving. In thiscase, segment locators associated with quality layers 1101 whichqualities are near (on the quality scale) to the quality currently beingwatched (1100) are suitable for pre-resolving. Segment locatorsassociated with quality layers 1102 with a quality far away from thequality currently being watched are not suitable for pre-resolving. Inone embodiment, the client may use a quality proximity parameterdefining a quality distance. The quality proximity parameter may be usedfor determining which segments identified in the manifest file are inclose quality proximity to the segment currently being played-out by theclient. Segments identified in the manifest file which are within thequality proximity distance from the currently watched segment may bemarked for pre-resolving.

FIG. 12 depicts the selection of suitable segments locators forpre-resolving according to yet another embodiment of the invention. Inparticular, FIG. 12 depicts a simple algorithm for the segment selectorto determine which segments locators in a manifest file associated witha spatially segmented video are suitable for pre-resolving. Thealgorithm determines a matrix of spatial segments wherein each spatialsegment is associated with content of a particular region (formed by thedotted lines) within the total area covered by the matrix of spatialsegments. A user may select and watch one particular spatial segment1201. Hence, when a user starts interacting with the content displayedon a terminal (e.g. through a panning operation) there is a large chancethat one or more segments that are directly bordering the segment thatis being watched are going to be selected by the user for play-out. Inthis situation, spatial segment locators suitable for pre-resolving arelocated directly around the segment that is watched. Hence, if the usernavigation information indicates that a spatial segment associated withparticular area x,y is played-out, the segment selector may select a setof further segment locators, e.g. spatial segments locators associatedwith areas at positions (x−1,y)(x−1,y−1)(x−1,y+1)(x,y+1)(x,y−1)(Sx+1,y)(x+1,y−1)(x+1,y+1) as segments locatorssuitable for pre-resolving. On the basis the user navigationinformation, the segment selector may determine that other spatialsegments are not (yet) suitable for pre-resolving. In one embodiment,the client may use a spatial proximity parameter defining a spatialdistance. Spatial segments associated with areas located within thespatial proximity distance from the currently watched spatial segment(s)may be marked pre-resolving.

FIG. 13 depicts at least part of a manifest file comprising anunresolved segment locator 1302 (as part of an URL) which is marked forpre-resolving according one embodiment of the invention. In thisparticular embodiment, a content provider or CDN provider may insertmarkers 1301 a, 1301 b for marking specific segment locators within amanifest file 1300. These markers may be inserted on the basis ofsegment navigation statistics so that popular segments, i.e. segmentsthat are frequently requested, can be identified by the client on thebasis of the markers in the manifest file. Such marker identifies asegment locator as being suitable for pre-resolving. In one embodiment,markers may be associated with a ranking value, e.g. a popularity score,so that unresolved segment locators may be ranked in accordance with aranking. These markers may thus provide a ranking scheme for the segmentselector to select one or more further segments locators for futuresegment requests. This way unresolved segment locators associated with ahigh popularity score may pre-resolved earlier than those with a lowerpopularity score. In one embodiment a content provider or a CDN mayinsert these markers into a manifest file. In another embodiment, acontent provider or a CDN may generate a new marked manifest file.

It is to be understood that any feature described in relation to any oneembodiment may be used alone, or in combination with other featuresdescribed, and may also be used in combination with one or more featuresof any other of the embodiments, or any combination of any other of theembodiments.

One embodiment of the invention may be implemented as a program productfor use with a computer system. The program(s) of the program productdefine functions of the embodiments (including the methods describedherein) and can be contained on a variety of computer-readable storagemedia. Illustrative computer-readable storage media include, but are notlimited to: (i) non-writable storage media (e.g., read-only memorydevices within a computer such as CD-ROM disks readable by a CD-ROMdrive, flash memory, ROM chips or any type of solid-state non-volatilesemiconductor memory) on which information is permanently stored; and(ii) writable storage media (e.g., floppy disks within a diskette driveor hard-disk drive or any type of solid-state random-accesssemiconductor memory) on which alterable information is stored. Theinvention is not limited to the embodiments described above, which maybe varied within the scope of the accompanying claims.

1. A method for enabling streaming of segmented content on the basis of a manifest file, said manifest file comprising one or more segment identifiers and one or more associated segment locators for locating one or more delivery nodes configured to deliver one or more segments, identified by said segment identifiers, to a client, said method comprising: requesting the delivery of at least one segment on the basis of a first segment identifier in said manifest file; on the basis of said first segment identifier, selecting a second segment identifier from said manifest file, said second segment identifier being associated with at least one expected future segment request; and pre-resolving at least part of a first segment locator associated with said selected second segment identifier for obtaining network information associated with said first segment locator.
 2. The method according to claim 1, wherein said network information comprises at least one of: information on at least part of a network address associated with at least part of said first segment locator; information indicating whether a first segment locator associated with said selected second segment identifier (i) points to a delivery node for delivery of a segment associated with said expected future segment request, or iii) points to a network node for redirection of said expected future segment request; or at least part of a second segment locator associated with said selected second segment identifier.
 3. The method according to claim 1, further comprising: pre-resolving at least part of said first segment locator into at least part of a second segment locator associated with said selected further segment identifier, if said first segment locator points to a network node for redirection.
 4. The method according to claim 1, further comprising: modifying said manifest file on the basis of said network information.
 5. The method according to claim 2, further comprising: modifying said manifest file on the basis of said at least part of said second segment locator.
 6. The method according to claim 1, wherein said pre-resolving comprises: sending a request for network information to a network node associated with said first segment locator; receiving a response message; and determining on the basis of said response message whether said first segment locator associated with said selected second segment identifier points (i) to a delivery node for delivery of a segment associated with said expected future segment request or (ii) to a network node for redirection of said expected future segment request.
 7. The method according to claim 6, wherein said request for network information comprises at least one of: an HTTP, RTSP or DNS protocol message.
 8. The method according to claim 1, wherein said pre-resolving is executed as a background process during at least part of the delivery of said at least one segment.
 9. The method according to claim 1, further comprising: selecting said second segment identifier on the basis of at least part of: a user profile of a user, a user navigation history, user interaction with the segmented content and/or a geo-location of the client and/or the user.
 10. The method according to claim 1 wherein said manifest file comprises one or more markers for marking one or more further segment identifiers for future segment requests, wherein said marker comprises a ranking value.
 11. The method according to claim 1, wherein said pre-resolving comprises: transmitting a request for network information to a first content delivery network (CDN), said request comprising at least said selected second segment identifier; said first CDN transmitting an inter-CDN request message comprising said selected second segment identifier, to a second CDN for negotiating future delivery of said segment identified by said selected second segment identifier; and said first CDN receiving an inter-CDN response message comprising location information said one or more delivery nodes configured to deliver a segment identified by said selected second segment identifier to a client, wherein, said inter-CDN request message comprises an indicator, allowing said second CDN to determine that the inter-CDN request message is associated with the pre-resolving of a segment locator.
 12. A client for client-controlled streaming of segmented content hosted on one or more delivery nodes in a network, said client comprising: a manifest cache for storing at least part of a manifest file, said manifest file comprising one or more segment identifiers and one or more associated segment locators for locating one or more delivery nodes configured to deliver one or more segments identified by said segment identifiers to said client; a segment retrieval function for requesting the delivery of at least one segment on the basis of a first segment identifier in said manifest file; a segment selector configured for selecting on the basis of said first segment identifier, a second segment identifier associated with at least one expected future segment request; and a pre-resolving function for pre-resolving at least part of a first segment locator associated with said second segment identifier for obtaining network information associated with said first segment locator.
 13. A network node for use with a client, said network node being associated with a first content delivery network (CDN) and configured for: receiving from a client a request for network information associated with a segment locator, said segment locator being associated with a segment identifier identifying a segment; and transmitting an inter-CDN request message comprising at least part of said segment locator and said segment identifier, to a second CDN for negotiating future delivery of said segment; wherein said inter-CDN request message comprises a flag allowing said second CDN to determine that said inter-CDN message is associated with the pre-resolving of a segment locator requested by said client.
 14. (canceled)
 15. A computer program product comprising software code portions configured for, when run in the memory of a computer, executing a method for enabling streaming of segmented content on the basis of a manifest file, said manifest file comprising one or more segment identifiers and one or more associated segment locators for locating one or more delivery nodes configured to deliver one or more segments, identified by said segment identifiers, to a client, said method comprising: requesting the delivery of at least one segment on the basis of a first segment identifier in said manifest file; on the basis of said first segment identifier, selecting a second segment identifier from said manifest file, said second segment identifier being; associated with at least one expected future segment request; and pre-resolving at least part of a first segment locator associated with said selected second segment identifier for obtaining network information associated with said first segment locator. 